Subagents与Teams：多代理协作入门
章节概述
前面的章节我们学会了用MCP扩展工具能力、用Skills扩展工作流程。本章介绍第三种扩展方式——Agent（代理）：让Claude Code派出一个专门的助手，自动完成你交办的任务。
一、从一个例子开始：创建一个代码审查Agent
1.1 跟我做：用 /agents 创建你的第一个Agent
打开Claude Code终端，输入：
/agents
text
界面有两个标签页：Running（正在运行的 Agent）和 Library（可用的 Agent 库，第一项就是 Create New Agent）。选中 Create New Agent 回车，走一遍交互式创建：
- 选作用域：项目级（
.claude/agents/，优先级更高、只在本项目生效）还是用户级（~/.claude/agents/，常用 Agent 放这里，所有项目可用） - 选创建方式：由 Claude 引导创建（推荐，回答几个问题就行）或手动编辑模板
- 描述用途：用一两句话说清"这个 Agent 干什么、什么时候用"，例如"创建一个前端开发助理，管理前端代码、帮助书写高质量前端代码，熟悉 Vue 和 React 生态"
- 勾选工具集：允许它读文件、编辑、执行命令、调用 MCP 等，按需勾选
- 选默认模型：Sonnet（速度与能力均衡）或 Opus（编码能力更强）
- 选个颜色：纯为了在列表里好认
完成后 Agent 出现在 Library 列表（项目作用域会单独分组），它生成的 .md 文件就是一段角色描述 + 规范，随时可以再编辑。整个过程和创建 Skill 的体验一致——都是"文本文件 + 引导生成"。
手动创建当然也行。在项目根目录创建 .claude/agents/reviewer.md：
<!-- .claude/agents/reviewer.md -->
---
name: reviewer
description: 代码审查助手，检查Vue3组件的代码质量
tools:
- Read
- Grep
---
你是一位前端代码审查专家。
## 职责
- 检查Vue3组件是否存在常见问题（内存泄漏、未清理的定时器、props类型缺失等）
- 检查TypeScript类型定义是否完整
- 检查是否有冗余代码或未使用的变量
- 输出问题清单，标注严重程度（高/中/低）
markdown
创建完成后，再输入 /agents，你会看到 reviewer 出现在列表中。
1.2 试试看：让Agent自动工作
假设你的项目中有一个 src/components/UserList.vue，直接对Claude Code说：
用 reviewer 检查 src/components/UserList.vue 的代码质量
text
看看发生了什么：
你：用 reviewer 检查 UserList.vue 的代码质量
↓
Claude Code 启动 reviewer Agent
├── 它自己读取 UserList.vue
├── 它自己逐项检查代码质量
└── 它自己输出问题清单
↓
完成！你只说了一句话。
text
你不需要告诉它"先读文件、再检查内存泄漏、再查类型定义"。你给一个目标，它自己规划步骤并执行。
这就是Agent。
除了自然语言点名，还可以用 @ 引用：在提示词里输入 @ 会弹出可选的 Agent 列表，选中 reviewer 后再描述任务，明确指定"这件事由它来干"。
1.3 Agent、Skills、MCP的区别
这三个概念容易混淆，用一张表说清楚：
| MCP | Skills | Agent | |
|---|---|---|---|
| 是什么 | 给Claude加工具 | 给Claude加知识/流程 | 给Claude加帮手 |
| 类比 | 给工人一把新扳手 | 给工人一本操作手册 | 雇一个新工人 |
| 谁在干活 | Claude自己用新工具干活 | Claude自己按手册干活 | 另一个Claude替你干活 |
| 例子 | 安装Playwright，Claude就能操作浏览器 | /local-search 告诉Claude怎么搜索 | /commit 派一个Agent去提交代码 |
| 主动性 | 被动——等Claude调用 | 被动——等Claude执行 | 主动——自己规划、自己执行 |
| 配置方式 | settings.json | .md文件 | .md文件 |
一句话区分：
- MCP回答"你能做什么"——有了Playwright，你能操作浏览器
- Skills回答"怎么做"——按这个流程去生成PPT
- Agent回答"谁来做"——让一个专门的家伙去处理
1.3 再看一个例子：Explore代理
当你让Claude Code搜索代码时：
你：帮我找一下项目中所有的组件文件
↓
Claude Code 启动 Explore Agent
├── 它自己决定搜索 src/components/
├── 它自己筛选 .vue 文件
└── 它自己返回结果
↓
结果：Button.vue、Input.vue、Modal.vue ...
text
你只说了一句话，Explore Agent自己决定了搜索策略。这就是Agent的自动性——你定目标，它定过程。
二、Agent的两种工作模式
实际使用中你不需要自己去选什么"委托模式""并行模式"，AI会根据任务自动判断用哪种方式。你只需要理解两种模式就够了：
单Agent模式
一个任务交给一个Agent处理。 这是最常见的情况。
你：帮我搜索项目中所有的组件文件
↓
Claude Code → Explore Agent → 返回结果
text
第一节创建的 reviewer Agent 也是这种——你一句话，一个Agent搞定。
Team模式
复杂任务由一个Team Lead协调多个Agent协作完成。
先开启：Agent Teams 目前是实验性功能
Team 模式默认关闭（官方文档标注 experimental），需要在 settings.json 的 env 里显式开启：
// ~/.claude/settings.json 或 .claude/settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
json
设为 1 后，Claude Code 会解锁一组团队工具（TeamCreate、TaskCreate、TaskUpdate、TaskList、SendMessage 等），并具备两个关键能力：共享任务清单（团队成员围绕同一份任务列表认领工作）和 Agent 间通信（互相发消息、汇报与接力）。不设这个变量，不会有任何团队行为。开启前把 Claude Code 升级到较新的版本。
用自然语言组建一个临时团队
开启后，直接在提示词里描述"组建什么样的团队"即可，比如官方文档的示例：
我正在设计一个CLI工具，帮助开发者追踪代码中的TODO注释。
请组建一个代理团队从不同角度进行探索：
一位负责用户体验、一位负责技术架构、一位扮演质疑者的角色。
text
实测一把（对本课程项目）：
请你组建一个团队：一个负责审核代码，一个负责项目的整体规划，
一个负责监督他们的工作、提出质量要求与质疑。
看看当前项目还需要从哪些角度进行优化与开发，哪些是有问题的部分。
text
执行过程：Claude 先快速了解项目（搜索文件、跑构建和类型检查）→ 创建团队并分配角色 → 三个成员并行工作、互相通信 → 各自完成后进入待命，监督者独立复查 → 输出综合报告（实测扫出了 54 处可优化点、虚拟滚动缺失等问题）→ 团队解散、资源清理。
两个实战要点：
- 用 bypassPermissions 模式跑团队任务。多 Agent 执行中如果每次编辑/删除文件都要人工确认，协作流程会被打断
- 临时团队只在当前会话有效。运行时创建的成员不会写入
.claude/agents/，会话结束即解散——这和固化的本地 Agent 是两种东西
来看一个例子：
你：帮我把项目中所有的API请求函数都加上错误处理和TypeScript类型
Team Lead（团队协调者）
├── 分析需求，拆解任务
├── 分配给团队成员
└── 跟踪进度，汇总结果
步骤1：Team Lead 拆解任务
├── search-agent → 找出所有API请求文件
├── dev-agent → 给每个函数加上 try-catch 和类型定义
└── test-agent → 验证修改后代码能正常运行
步骤2：Agent之间协作
search-agent 返回：api/user.ts、api/order.ts、api/product.ts
↓ 通知 dev-agent
dev-agent 修改 api/user.ts，通知 test-agent 运行测试
↓
test-agent 发现 api/order.ts 的类型有问题，反馈给 dev-agent
↓
dev-agent 修复后，再通知 test-agent 验证
↓ 全部通过
步骤3：Team Lead 汇总结果
[Team Lead] → 你："已完成。修改了3个文件，添加了错误处理和类型定义，测试全部通过。"
text
Team模式的核心是Team Lead——它不干活，只负责：
- 拆解任务：把你的需求分解成多个子任务
- 分配工作：把子任务分给合适的Agent
- 协调沟通：Agent之间互相传递信息（比如测试发现问题反馈给开发）
- 汇总结果：把所有Agent的产出整合后交给你
你不需要逐个创建团队成员——开关打开后，用一句自然语言描述"要一个什么样的团队"（角色+各自职责），Claude Code 会在运行时自行创建和组织。要不要固化，判断标准很简单：这个角色以后还会反复用 → 写成 .claude/agents/ 里的本地 Agent 文件；只是一次性复杂任务 → Team 模式临时组队，用完即散。
简单理解： 单Agent模式就是一个工人干活；Team模式就是一个工头带几个工人协作。用哪个，AI来决定。
三、自定义Agent
3.1 什么时候需要自定义
内置Agent（Explore、Plan 等）覆盖了常见场景。但你的项目可能有特殊需求：
- "组件必须用
<script setup lang="ts">语法" - "测试框架是vitest，不用jest"
- "commit message必须是中文"
这时候你可以在 .claude/agents/ 目录下创建自定义Agent。
3.2 创建自定义Agent
<!-- .claude/agents/component-dev.md -->
---
name: component-dev
description: Vue3组件开发专家
tools:
- Read
- Write
- Edit
- Bash
- Grep
---
你是一位Vue3组件开发专家。
## 代码规范
- 使用 `<script setup lang="ts">` 语法
- Props使用 `defineProps<T>` 泛型定义
- 组件命名采用PascalCase
markdown
创建后Claude Code会自动识别。当涉及组件开发任务时，它会参考这个Agent的规范。
3.3 Prompt设计要点
| 原则 | 好的做法 | 不好的做法 |
|---|---|---|
| 角色明确 | "你是Vue3组件开发专家" | "你是一个AI助手" |
| 边界清晰 | "只负责组件逻辑" | "帮我做好这个项目" |
| 有具体规范 | "用TypeScript严格模式，PascalCase命名" | "按最佳实践来" |
四、什么时候该用/不该用
不需要多Agent
- 修改一个bug、添加一个简单功能
- 搜索或查看代码
- 重构一个文件
适合用多Agent
- 大型重构（同时改多个模块）
- 组件库开发（组件+测试+文档并行）
- 批量操作（同时处理多个文件）
经验法则
独立子任务 ≤ 2 个 → 单Agent够了
独立子任务 3~5 个 → 并行Agent
需要多角色互相配合 → Team模式
text
五、扩展视野：Agent相关的工具生态
学完Claude Code的Agent系统后，你可能想了解更多相关工具。这些工具分为两类：
多Agent开发框架——用代码定义Agent角色和行为，给开发者用：
| 框架 | 开发语言 | 学习曲线 | 特点 |
|---|---|---|---|
| Claude Code | - | 低 | 内置，开箱即用，适合日常开发 |
| CrewAI | Python | 低 | 代码定义Agent角色和任务，适合快速原型 |
| LangGraph | Python | 中高 | 基于图的工作流编排，适合复杂生产环境 |
| AutoGen | Python/.NET | 中 | 微软出品，企业级支持 |
AI应用编排平台——可视化拖拽编排AI工作流，给非开发者用：
| 工具 | 价格 | 特点 | 适合谁 |
|---|---|---|---|
| Coze（字节） | 已宣布分阶段下线 | 拖拽式Bot搭建；企业版最晚2027年底全面停服 | 存量用户迁移中，新项目不建议 |
| Dify | 免费+299元/月 | 可视化编排，支持私有化 | 企业级应用 |
| FastGPT | 免费+付费 | 知识库驱动的工作流 | 知识库问答产品 |
| n8n | 免费+付费版 | 开源自动化工作流，节点丰富 | 自动化集成场景 |
两者的区别： Agent框架用代码定义Agent行为，灵活度高；编排平台用拖拽搭建AI应用，上手门槛低。课程学的是前者。
顺带一个趋势词：现在社区常说的 Harness Engineering（驾驭工程），本质上就是在 Agent/Skills/MCP 这些底层能力之上，去扩展模型的自主性和工具面——Claude Code 本身就是一个 harness。理解了 Agent/Skills/MCP/Team 这几个原语，再看那些新出的 Agent 产品和编排平台，拆开都是同一套东西。
再往远看一步：多个终端窗口各跑一个 Claude Code 会话、用共享上下文的插件打通、再以团队模式共享消息——"一人公司"在 AI 时代并不夸张。七八个 AI 同时替你干活时，效率不是线性提升的。前提是你要有一个趁手且熟悉的 harness。
六、总结
- Agent = 自动干活的帮手——你给目标，它自己规划执行
- 和MCP/Skills的区别——MCP加工具，Skills加流程，Agent加人手
- 两种模式——单Agent和Team，用哪个由AI自动决定
- 自定义很简单——在
.claude/agents/写一个.md文件 - 不用纠结模式选择——大多数时候你只需要说清楚要做什么
七、延伸：Coze 下线与 AI 工作流的何去何从（2026-11-08 补充）
上面表格里的 Coze 已经成为历史：2026 年 10 月 29 日，字节跳动发布《扣子「企业版」下线公告》——企业版 11 月 30 日起停止新售，火山引擎旧版套餐 2026 年 12 月 31 日全面下线，新版企业套餐最晚 2027 年 12 月 31 日全面停服，连对话、记忆、工作流等资源的导出方案在公告发布时都尚未确定。而这并非突然发生：此前一年扣子已密集收缩——专业版 5 月底停服、20 余款第三方模型分批下架、海外版 Coze.com 在 9 月把触发器、长期记忆、多智能体、日志、评测这些「上生产环境必备」的能力全部砍掉。一个 2025 年还以 19.3% 份额位居中国智能体开发平台公有云市场第一的产品，为什么说退就退？
三个原因叠加，缺一个都退不了。 第一，它解决的问题消失了：拖拽式可视化工作流的本质，是给「模型不够强、不会自己规划」的年代，让人类把步骤画成一张有向无环图给 AI 照着走；到 2026 年，模型已经能用自然语言直接驱动复杂任务、自己规划自己修正，人类代劳的编排被模型本体吃掉了。而且工作流范式天生缺「环」——DAG 只能从起点一次走到终点，Agent 干活最需要的「试错—观察—修正—再执行」循环它给不了，版本管理、CI/CD、环境隔离这些生产级工程能力在画布上也做不出来：零代码对小白不够简单，对企业又不够可靠。第二，盘子撑不起一条产品线：2025 年中国智能体开发平台公有云市场全年规模仅约 2.5 亿元，19.3% 份额折算平台收入不足五千万元，市场第一也只是「边缘成本」。第三，字节的「粗主干」战略收拢：飞书与豆包团队合并、TRAE 和扣子团队并入豆包体系、统一品牌「豆包工作」——AI 时代算力太贵，赛马机制玩不起了；办公 Agent 这仗由豆包去打，算力和企业交付归火山引擎，夹在中间的独立扣子失去了存在理由。
那 AI 工作流何去何从？四个判断： ①可视化拖拽平台的蜜月期结束了，但需求没消失——迁移到 Dify（开源可私有化、模型自由）、腾讯云 ADP、阿里百炼、n8n 时，选型第一问应该是「退出成本」：绑在私有画布上的工作流不是你的资产，说没就没。②资产形态决定抗风险能力：值得积累的是 AI 可读、可迁移、可审查的流程定义——用代码和开放格式表达业务逻辑（这正是本课程选 Agent 框架而不是编排平台的原因），而不是坐标和 UI 元数据。③人的能力重心从「会拖拽」转向「能兜底」：低代码平台一天能搭出 80 分的智能体，「连线和写提示词」正在快速贬值，稀缺的是剩下那 20%——把模糊的业务规则转成确定性逻辑：状态机、异常回滚、合规校验、评估体系、可观测性；模型负责聪明，人负责靠谱。④Agent 协作的协议层正在标准化：MCP、A2A 这类「多智能体的 TCP/IP」成熟后，任务分派、状态同步、冲突解决有了可复用的基础设施——课程后面讲的多 Agent 协作与 MCP 宿主化，正是在这个方向上提前卡位。
事实核查：下线时间线与原因分析经 local-search 核实（2026-11-08，来源：扣子官方下线公告 docs.coze.cn、腾讯云开发者社区、掘金深度分析「当补丁谢幕」）。
下一章将介绍Hooks自动化，学习如何通过事件驱动实现更智能的工作流。
↑